Dynamic generation of policy enforcement rules and actions from policy attachment semantics

ABSTRACT

At least one defined service policy to be enforced by a policy enforcement point (PEP) is obtained. The obtained at least one defined service policy is parsed to identify at least one set of enforceable policy provisions and the at least one set of enforceable policy provisions is identified. Each set of enforceable policy provisions includes a policy subject, a policy domain, and at least one assertion as the enforceable policy provisions within the at least one defined service policy. At least one runtime processing rule including at least one processing action usable by the PEP is created to enforce the policy subject, the policy domain, and the at least one assertion of each identified at least one set of enforceable policy provisions.

RELATED APPLICATIONS

This application is a continuation of and claims priority to and claimsthe benefit of U.S. patent application Ser. No. 13/764,828 titled“DYNAMIC GENERATION OF POLICY ENFORCEMENT RULES AND ACTIONS FROM POLICYATTACHMENT SEMANTICS,” which was filed in the United States Patent andTrademark Office on Feb. 12, 2013, and which is incorporated herein byreference in its entirety.

This application is further related to U.S. patent application Ser. No.13/764,847 titled “APPLYING POLICY ATTACHMENT SERVICE LEVEL MANAGEMENT(SLM) SEMANTICS WITHIN A PEERED POLICY ENFORCEMENT DEPLOYMENT,” whichwas filed in the United States Patent and Trademark Office on Feb. 12,2013, to U.S. patent application Ser. No. 13/764,864 titled “POLICYASSERTION LINKING TO PROCESSING RULE CONTEXTS FOR POLICY ENFORCEMENT,”which was filed in the United States Patent and Trademark Office on Feb.12, 2013, and to U.S. patent application Ser. No. 13/764,895 titled“INSTRUMENTATION AND MONITORING OF SERVICE LEVEL AGREEMENT (SLA) ANDSERVICE POLICY ENFORCEMENT,” which was filed in the United States Patentand Trademark Office on Feb. 12, 2013, each of which is herebyincorporated by reference as if fully set forth herein.

BACKGROUND

The present invention relates to service level agreement (SLA) policyenforcement. More particularly, the present invention relates to dynamicgeneration of policy enforcement rules and actions from policyattachment semantics.

Service level agreements (SLAs) are contracts for services formedbetween consumers and service providers. For example, a consumer mayenter into a service level agreement with a service provider to sendand/or receive an agreed number of messages (e.g., text messages) permonth for a contracted/set fee. The SLA may further specify that if theconsumer exceeds the agreed number of messages per month associated withthe contracted/set fee, an additional per message fee will be chargedfor each additional message.

BRIEF SUMMARY

A method includes obtaining, by a processor, at least one definedservice policy to be enforced by a policy enforcement point (PEP);parsing the obtained at least one defined service policy to identify atleast one set of enforceable policy provisions; identifying the at leastone set of enforceable policy provisions, where each set of enforceablepolicy provisions comprises a policy subject, a policy domain, and atleast one assertion as the enforceable policy provisions within the atleast one defined service policy; and creating at least one runtimeprocessing rule comprising at least one processing action usable by thePEP to enforce the policy subject, the policy domain, and the at leastone assertion of each identified at least one set of enforceable policyprovisions.

A system includes a memory and a processor programmed to obtain at leastone defined service policy to be enforced by a policy enforcement point(PEP); parse the obtained at least one defined service policy toidentify at least one set of enforceable policy provisions; identify theat least one set of enforceable policy provisions, where each set ofenforceable policy provisions comprises a policy subject, a policydomain, and at least one assertion as the enforceable policy provisionswithin the at least one defined service policy; and create within thememory at least one runtime processing rule comprising at least oneprocessing action usable by the PEP to enforce the policy subject, thepolicy domain, and the at least one assertion of each identified atleast one set of enforceable policy provisions.

A computer program product includes a computer readable storage mediumhaving computer readable program code embodied therewith, where thecomputer readable program code when executed on a computer causes thecomputer to obtain at least one defined service policy to be enforced bya policy enforcement point (PEP); parse the obtained at least onedefined service policy to identify at least one set of enforceablepolicy provisions; identify the at least one set of enforceable policyprovisions, where each set of enforceable policy provisions comprises apolicy subject, a policy domain, and at least one assertion as theenforceable policy provisions within the at least one defined servicepolicy; and create at least one runtime processing rule comprising atleast one processing action usable by the PEP to enforce the policysubject, the policy domain, and the at least one assertion of eachidentified at least one set of enforceable policy provisions.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

FIG. 1 is a block diagram of an example of an implementation of a systemfor dynamic generation of policy enforcement rules and actions frompolicy attachment semantics according to an embodiment of the presentsubject matter;

FIG. 2 is a block diagram of an example of an implementation of a coreprocessing module capable of performing dynamic generation of policyenforcement rules and actions from policy attachment semantics accordingto an embodiment of the present subject matter;

FIG. 3 is a diagram of an example of an implementation of a policytransformation flow for dynamic generation of policy enforcement rulesand actions from policy attachment semantics for a service leveldefinition (SLD) according to an embodiment of the present subjectmatter;

FIG. 4 is a diagram of an example of an implementation of a policytransformation flow for dynamic generation of policy enforcement rulesand actions from policy attachment semantics for a service leveldefinition (SLD) and service level agreements (SLAs), and runtimeenforcement according to an embodiment of the present subject matter;

FIG. 5 is a diagram of an example of an implementation of a policytransformation flow for dynamic generation of policy enforcement rulesand actions from policy attachment semantics for a service leveldefinition (SLD) and service level agreements (SLAs) based upon theexample SLD and SLAs described in FIG. 4 according to an embodiment ofthe present subject matter;

FIG. 6 is a flow chart of an example of an implementation of a processfor dynamic generation of policy enforcement rules and actions frompolicy attachment semantics according to an embodiment of the presentsubject matter;

FIG. 7 is a flow chart of an example of an implementation of a processfor dynamic generation of policy enforcement rules and actions frompolicy attachment semantics for both service level definitions (SLDs)and service level agreements (SLAs) according to an embodiment of thepresent subject matter; and

FIG. 8 is a flow chart of an example of an implementation of a processfor dynamic deployment and enforcement of policy enforcement rules andactions at policy enforcement points (PEPs) according to an embodimentof the present subject matter.

DETAILED DESCRIPTION

The examples set forth below represent the necessary information toenable those skilled in the art to practice the invention and illustratethe best mode of practicing the invention. Upon reading the followingdescription in light of the accompanying drawing figures, those skilledin the art will understand the concepts of the invention and willrecognize applications of these concepts not particularly addressedherein. It should be understood that these concepts and applicationsfall within the scope of the disclosure and the accompanying claims.

The subject matter described herein provides dynamic generation ofpolicy enforcement rules and actions from policy attachment semantics.The present technology involves automated policy transformation andruntime enforcement to allow policies within a policy domain (e.g.,service provider policy domain, etc.) to be associated with any runtimeobject (e.g., objects representing specific consumers, organizations,service resources, etc.) that needs to be controlled or regulated bythat policy. Those policies may be enforced against the runtimeobject(s) at policy enforcement points (PEPs) that operate to provideproxy service offerings including policy enforcement. Examples ofruntime objects against which policies may be enforced includetransactions, web requests, database requests, representational statetransfer (REST) services, and web applications. The control orregulation of the runtime object by policy may be further determinedbased upon the content of that object at runtime, such as usercredentials. Policies may be attached at an object level for an object,thereby enhancing the specificity of policy enforcement based upon thegranularity of the respective objects (e.g., at the level of specificconsumers, organizations, service resources, etc.) and based upon thecontent of those objects at runtime.

To implement the present technology, a device, such as a PEP,programmatically and dynamically transforms defined service policies,which are defined using policy attachment semantics, into runtimeprocessing rules that encapsulate runtime processing actions(collectively runtime “policy enforcement rules”) that are to beexecuted against runtime objects to enforce the provisions (e.g.,defined via the policy attachment semantics) of the defined policies. Totransform the defined service policies, the device obtains one or moredefined service policies to be enforced by the PEP. The defined servicepolicies that are obtained are parsed to identify enforceable policyprovisions, such as policy constraints (e.g., number of messages peragreement). A policy subject, a policy domain, and one or moreassertions are identified as the enforceable policy provisions withineach defined service policy. Additionally, an optional policy scheduleand policy effective dates may be included in policy attachments. One ormore runtime processing rules that include at least one processingaction usable by the PEP to enforce the identified policy subject,policy domain, and the assertion(s) of each defined service policy aredefined. The PEP may then apply the defined processing rules and theencapsulated processing actions against runtime objects to enforce theoriginal service policy definitions.

To transform the defined service policies into the runtime processingrules and processing actions, intermediate proxy policy objects arecreated that operate as intermediate effective policies. The proxypolicy objects support the proxy service offerings and constraints forpolicy enforcement provided by PEPs, as described herein. The creationof policy enforcement rules that include runtime processing rules andprocessing actions to support the runtime enforcement of definedpolicies involves the creation of these intermediate policy proxyobjects that include information from the original policy that is undertransformation. These intermediate policy proxy objects provide aframework and foundation for creation of the actual runtime policyenforcement rules including the processing rules and processing actions.

The present technology may be applied, for example, to implement servicelevel agreements (SLAs) within a service oriented architecture (SOA)network appliance engine. The present technology may be implemented, forexample, using higher-level gateway platform actions rather thanlow-level code. As such, implementation may be performed at a layer ofabstraction above the encoding level for the respective applianceengines. It should be noted that the present technology may beimplemented with a variety of policy constructs and is not limited toparticular variations of how policies are constructed. Accordingly, thepresent technology may be flexibly applied across a variety of serviceplatforms.

It should be noted that conception of the present subject matterresulted from recognition of certain limitations associated with policyadministration and enforcement. For example, it was observed that policyadministrators are tasked with implementing and maintaining policies tosupport service level definitions (SLDs) and service level agreements(SLAs), and that the domain of policy enforcement has becomeincreasingly complex as systems have increased in size and feature sets.This process of having administrators manually implement and maintainpolicies was observed to be a time consuming task that is prone toerrors, particularly due to the increased size and complexity of thesystems and feature sets available within these systems. For example, itwas observed that where multiple SLAs are attached to a service,subsequent changes that affect multiple consumers may require theidentification and editing of multiple configured policy enforcementrules and actions associated with those policy enforcement rules, butthat identification of all applicable policy enforcement rules andactions was difficult. It was further observed that manual updating ofthe applicable policy enforcement rules that were able to be identifiedmay require extensive efforts, and that this processing is again proneto errors. It was further determined that there are several issues thathave arisen with the increased size and complexity of policyadministration and enforcement systems. For example, it was determinedthat scalability cost, maintainability, agility, and operationalstability are all factors to be addressed within policy administrationand enforcement for such system implementations. As such, in view of theobservations and determinations described above, the present subjectmatter improves policy administration and enforcement by providing fordynamic generation of policy enforcement rules and actions from policyattachment semantics, as described above and in more detail below.

Several definitions are utilized within the following description, andsome are repeated and further defined below. The term “service policy”or “policy” as utilized herein represents any mediation enforcementprovision, routing provision, security provision, or any other custompolicy/provision that is written to a specification that a policyenforcement system may implement. As such, a service policy may beimplemented as a web service (e.g., web services description language(WSDL)), as a representational state transfer (REST) implementation orservice, as a web application (e.g., plain old XML (PDX))implementation, as a database request, or otherwise as appropriate forthe given implementation.

Regarding service policies, a service level agreement (SLA) is a servicepolicy that represents an agreement (e.g., a contract for services)between a service provider and a consumer where a level of service isformally defined and agreed between the parties to the SLA. The SLArecords a common understanding about services, priorities,responsibilities, guarantees, warranties, and any other particulars ofthe agreement. Examples of SLAs include business services such as a webservice, a REST service, and a web application. The SLA may specify, forexample, the levels of availability, serviceability, performance,operation, or other attributes of the service to be provided by theservice provider to the consumer. As a further example, an SLA mayrepresent a processing agreement such as a transaction rate, a processorutilization level, a disk utilization level, and a memory utilizationlevel for the business service.

A service level definition (SLD) represents a service policy thatprotects the service provider infrastructure access and utilizationconstraints, such as for example from accesses by non-contractingentities for which an SLA has not been established, or to limit amaximum resource utilization to prevent service degradation (e.g.,maximum number of messages per minute). An SLD, when attached to apolicy subject, is enforced by a policy enforcement point (PEP). A“policy subject” represents an entity with which a policy (e.g., an SLAor SLD) may be associated, such as for example, an endpoint of atransaction, a message, a resource, an operation or other entity.

A policy administration point (PAP) represents a location (e.g.,repository, registry, etc.) where policies such as SLAs and SLDs may becreated, stored, accessed, and modified. A WebSphere® service registryand repository (WSRR) represents one possible example of a PAP. A policyenforcement point (PEP) represents an intermediary system that operatesto enforce defined policies. The PEP provides proxy service offeringsincluding policy enforcement. A “policy framework” represents theinfrastructure used to convert supported policy vocabularies intoprocessing actions and processing rules.

Regarding transformation of service policies, as a first phase of policytransformation, a service policy is transformed into one or moreintermediate (or local) policy entities. The intermediate policyentities are termed herein in the alternative as a “proxy policy,” a“proxy policy object,” and an “effective policy.” Each of these termsrepresents an intermediate policy entity created based upon informationwithin the original service policy (e.g., SLD or SLA, etc.) that may beused to create runtime enforcement logic to enforce the respectiveservice policies.

As a second phase of policy transformation, the intermediate proxypolicy entities are transformed into one or more “processing actions”that represents an atomic unit of behavior defined based upon a policyto be implemented by a PEP. A “processing rule” or “policy enforcementprocessing rule” as described herein represents an ordered sequence ofprocessing actions defined based upon a policy to be implemented by aPEP. One or more processing rules may be collected into a “policyenforcement rule.” As such, the term “policy enforcement rule” as usedherein represents one or more processing rules to be enforced to performpolicy enforcement. An “SLA check” represents a gateway operation at aPEP that is used to determine the SLA policy enforcement rules createdfrom defined policies that are to be implemented during runtime by thatPEP and applied to a particular transaction (e.g., to a message).

For example, a policy may be specified as an SLA between a serviceprovider and a consumer. Each consumer may have its own selected serviceoptions. As such, for purposes of the present example, it is assumedthat two consumers have selected different service plans for aparticular service. Within this example, one consumer has selected a“default” service level defined within the service provider domain forthis particular service offering at a level of one hundred (100) allowedrequests per hour. Similarly, another consumer has selected ahigher-tier service level, identified within the present example as a“gold” service level, with a service offering of five hundred (500)allowed requests per hour. As such, enforcement of this SLA by a PEPwould involve identification of the respective consumers, correlation ofthe respective consumers with their selected service plans/levels, andmonitoring of request rates (e.g., message rates, transaction rates,etc.) for each consumer based upon their respective selected plans. If athreshold number of requests per hour associated with a selected plan isreached, the PEP would then invoke processing to identify any additionalservice requests as overages relative to the plan or prevent the servicerequests, as appropriate for a given implementation. Similarly, if aconsumer issues a request that is authorized based upon the selectedservice plan, the PEP is responsible for ensuring that the request issatisfied for the consumer by the service provider.

The present technology enhances policy enforcement point (PEP)functionality to transform defined service policies (e.g., SLAs andSLDs) associated with a policy administration point (PAP) into policyenforcement rules and actions that are enforced by the PEP. Theautomated transformation of the defined policies involves transformationfrom the defined policy definitions/semantics to policy enforcementrules and actions that are operable by the PEP platform to enforce thedefined policies. The policy enforcement rules and actions aredynamically implemented and enforced on a transactional basis duringruntime as transactions associated with the defined policies occur(e.g., as messages are received).

Example transformations include transformation of a defined servicepolicy into one or more processing actions in a normalized andinterchangeable format. The normalized and interchangeable format mayinclude, for example, a language such as extensible markup language(XML), XML stylesheet language for transformations (XSLT),object-oriented languages such as Java™ and C++ programming languages,relational database management (RDBM) languages such as structured querylanguage (SQL), and scripting languages/implementations such as PHP:Hypertext Preprocessor (PHP) and Perl.

It should be noted that the PEP processing technology described hereinoperates as a proxy for both the service providers and the consumers toenforce the various provisions of defined SLAs and SLDs. As such, thePEP represents a proxy component/entity for both the service provider(s)and for the consumer(s). Within this proxy context for policyenforcement, the PEP operates to protect the interests of the serviceproviders to ensure that no unauthorized consumers access the respectiveservices provided by the service providers and to ensure that consumersthat are authorized do not exceed the defined SLDs associated with theservices and service providers. Similarly, the PEP operates to protectthe interests of consumers and service providers to ensure that theSLA(s) for which the consumers and service providers have contracted areupheld/enforced. To fulfill this dual-proxy role, the PEP operates as aproxy intermediary for both of the respective entities to analyzemessages communicated between the respective entities and to enforcepolicy enforcement rules that are defined in association with the PEPbased upon policies associated with the respective services andagreements.

As described above, the present technology provides for the programmaticcreation of policy enforcement rules populated with processing actionsfrom policies defined in association with the respective services andagreements. The following pseudo-syntax policy example represents onepossible implementation of a defined service policy for which policyenforcement rules populated with processing actions may beprogrammatically created, and that may be enforced by a PEP.

<wsp:Policy> <dpe:summary> <description> Implements WS Security Policy1.1 - UsernameToken 1.0 support </description> </dpe:summary><wsp:ExactlyOne> <!--UsernameToken 10 --> <wsp:All><sp:SupportingTokens> <wsp:Policy> <sp:UsernameTokensp:IncludeToken=“IncludeToken/Always”> <wsp:Policy><sp:WssUsernameToken10/> </wsp:Policy> </sp:UsernameToken> </wsp:Policy></sp:SupportingTokens> </wsp:All> </wsp:ExactlyOne> </wsp:Policy>

Based upon the pseudo-syntax policy example above, a “UserNameToken 1.0”is defined with an “ExactlyOne” constraint (represented via a tag pair),such that only one user name token may be present in any message proxiedby a PEP. Additionally, the pseudo-syntax policy example above furtherspecifies that the user name token must always be present within anymessage by specifying the “IncludeToken/Always” constraint (representedvia an additional tag pair). A policy of “sp:WssUsernameToken10”represents a policy to be enforced for all messages (also representedwithin an additional tag pair) that identify the username token versionone (1.0) (“Basic Auth”) is required.

Attaching the “UserNameToken 1.0” policy to a service that is proxied bya PEP results in a filter action being programmatically created. Thefilter action may be implemented to analyze incoming messages and todetermine whether the specified components are part of the incomingmessage. If the specified components are not present within a particularincoming message, the message is rejected. If the specified componentsare present, the message is allowed to continue. As such, it is by thecreation and implementation of the message filtering action from theoriginal policy that the “UserNameToken 1.0” policy is enforced by thePEP.

The following pseudo-syntax policy enforcement rule example may beprogrammatically created from the pseudo-syntax policy example above forenforcement within a PEP.

Service_18_6-1-2-request-rule-suptoken mAdminState enabled UserSummaryhandle-supporting-token Type filter Input INPUT Transformstore:///required-elements-filter.xsl Output NULL NamedInOutLocationTypedefault Transactional off SOAPValidation body SQLSourceType staticAsynchronous off ResultsMode first-available RetryCount   0RetryInterval 1000 IteratorType XPATH Timeout   0 MethodRewriteType GETMethodType POST MethodType2 POST

As can be seen from the pseudo-syntax policy enforcement rule exampleabove, the policy enforcement rule is “enabled” within the “mAdminState”field, a “Type” of “filter” is specified, and the filtering action isapplied to the “INPUT” stream specified in the “Input” field. The“Transform” field specifies a stylesheet to execute as part of policyaction. The “Output” field specifies the name of a stream where theoutput of the action is to be stored.

As such, a policy framework, as described in more detail below, consumespolicies, such as the pseudo-syntax policy example above for enforcementby a PEP. To enforce the respective policies, the policy frameworkgenerates policy enforcement rules that include processing actions, suchas the example filtering action described above for messages to enforcethe associated policy. It should be noted that consumption of definedservice policies and transformation of those service policies toenforceable processing rules and processing actions may be repeated withconsistency of results. As such, one device, such as a PEP, may beconfigured to consume and transform policies to create processing rules,and to distribute the created processing rules to other PEPs forenforcement along with enforcement by the PEP that performed thetransformation, which provides one possible option for consistent policyenforcement results across multiple of PEPs. Alternatively, each PEP ofa multiple PEP environment may be configured to consume and transformservice policies into processing rules with consistent transformationresults across a set of PEPs, which may also result in consistent policyenforcement results. As such, a variety of policy transformationprocessing options may be available and utilized based uponimplementation details as appropriate for the respective implementation.

Further, as policies change over time, the associated policy enforcementrules and processing actions may be modified, added, deleted, orotherwise changed to implement any changes to the respective policiesthat have changed. As such, the present technology may provide forrepeatability of implementation. The present technology may furtherimprove scalability of costs, maintainability, agility, and operationalstability.

The dynamic generation of policy enforcement rules and actions frompolicy attachment semantics described herein may be performed in realtime to allow prompt creation of policy enforcement rules and run-timeactions from registered SLA policy attachment semantics. For purposes ofthe present description, real time shall include any time frame ofsufficiently short duration as to provide reasonable response time forinformation processing acceptable to a user of the subject matterdescribed. Additionally, the term “real time” shall include what iscommonly termed “near real time”—generally meaning any time frame ofsufficiently short duration as to provide reasonable response time foron-demand information processing acceptable to a user of the subjectmatter described (e.g., within a portion of a second or within a fewseconds). These terms, while difficult to precisely define are wellunderstood by those skilled in the art.

FIG. 1 is a block diagram of an example of an implementation of a system100 for dynamic generation of policy enforcement rules and actions frompolicy attachment semantics. A computing device_(—)1 102 through acomputing device_N 104 represent consumer client devices that utilizeservices specified by SLAs. The computing device_(—)1 102 through thecomputing device_N 104 may communicate with one another and with otherdevices via a network 106. A policy enforcement server_(—)1 108 througha policy enforcement server_T 110 represent policy enforcement points(PEPs), as described above. The policy enforcement server_(—)1 108through the policy enforcement server_T 110 communicate and interconnectvia a network 112 with a policy registry 114 that stores policies (e.g.,SLDs and SLAs) generated by one or more of a service providerserver_(—)1 116 through a service provider server_M 118. It should benoted that the network 106 and the network 112 are illustrated asseparate networks for ease of description, and that any arrangement ofinterconnection may be utilized as appropriate for a givenimplementation.

The service provider server_(—)1 116 through the service providerserver_M 118 represent service capable devices (e.g., messaging devicesfor text messages, etc.). The service provider server_(—)1 116 throughthe service provider server_M 118 also represent administrative devicesthat may be utilized by service provider administrators for policycreation, such as creation of SLDs and SLAs.

As described above, policies implemented by service provideradministrators via devices, such as the service provider server_(—)1 116through the service provider server_M 118, may be stored within thepolicy registry 114 for enforcement by PEPs, such as the policyenforcement server_(—)1 108 through the policy enforcement server_T 110.The policy enforcement server_(—)1 108 through the policy enforcementserver_T 110 each implement a policy framework as described above and inmore detail below for transformation of defined service policies storedin the policy registry 114 into policy enforcement rules that includeprocessing rules and processing actions that are to be enforced duringruntime against objects. The objects may be of varying granularity(e.g., at the level of specific consumers, organizations, serviceresources, etc., as described above) based upon the particular scope andconfiguration of the respective policies to be enforced for therespective service providers and consumers.

A PEP may be implemented via each of the policy enforcement server_(—)1108 through the policy enforcement server_T 110. The PEP has the role ofenforcing policies defined outside or within the PEP. The PEPs operateas gateways that provide virtual services that proxy policy enforcementoperations for the real backend services. The PEPs protect and optimizetransactions flowing through the respective network(s) on behalf of thebackend services. As such, the policy enforcement server_(—)1 108through the policy enforcement server_T 110 each represent proxygateways that provide proxy services for the service providersrepresented by the service provider server_(—)1 116 through the serviceprovider server_M 118 and for consumers represented by the computingdevice_(—)1 102 through the computing device_N 104.

It should be noted that there may be a many-to-one relationship of PEPsto service providers. Each PEP may create its own policy enforcementrules based upon policies to be enforced for a given service provider.By use of the present technology, the policy enforcement rule creationfrom defined policies may be consistently repeated across the set ofPEPs that are designated to enforce the respective policies.

As will be described in more detail below in association with FIG. 2through FIG. 8, the policy enforcement server_(—)1 108 through thepolicy enforcement server_T 110 may each provide automated dynamicgeneration of policy enforcement rules and actions from policyattachment semantics. The automated dynamic generation of policyenforcement rules and actions from policy attachment semantics is basedupon creation of the policy enforcement rules and actions to be enforcedduring runtime to fulfill the respective SLDs and SLAs established formessaging management within the system 100. A variety of possibilitiesexist for implementation of the present subject matter, and all suchpossibilities are considered within the scope of the present subjectmatter.

It should be noted that any of the respective computing devicesdescribed in association with FIG. 1 may be portable computing devices,either by a user's ability to move the respective computing devices todifferent locations, or by the respective computing device's associationwith a portable platform, such as a plane, train, automobile, or othermoving vehicle. It should also be noted that the respective computingdevices may be any computing devices capable of processing informationas described above and in more detail below. For example, the respectivecomputing devices may include devices such as a personal computer (e.g.,desktop, laptop, etc.) or a handheld device (e.g., cellular telephone,personal digital assistant (PDA), email device, music recording orplayback device, tablet computing device, e-book reading device, etc.),a service provider messaging server, a web server, application server,or other data server device, or any other device capable of processinginformation as described above and in more detail below.

The network 106 and the network 112 may include any form ofinterconnection suitable for the intended purpose, including a privateor public network such as an intranet or the Internet, respectively,direct inter-module interconnection, dial-up, wireless, or any otherinterconnection mechanism capable of interconnecting the respectivedevices.

FIG. 2 is a block diagram of an example of an implementation of a coreprocessing module 200 capable of performing dynamic generation of policyenforcement rules and actions from policy attachment semantics. The coreprocessing module 200 may be associated with either the policyenforcement server_(—)1 108 through the policy enforcement server_T 110to implement the dynamic generation of policy enforcement rules andactions from policy attachment semantics described herein. It should,however, be noted that components of the core processing module 200 mayadditionally or alternatively be associated with the computingdevice_(—)1 102 through the computing device_N 104 or with the serviceprovider server_(—)1 116 through the service provider server_M 118, asappropriate for a given implementation. As such, the core processingmodule 200 is described generally herein, though it is understood thatmany variations on implementation of the components within the coreprocessing module 200 are possible and all such variations are withinthe scope of the present subject matter.

Further, the core processing module 200 may provide different andcomplementary processing of policy enforcement rule creation and policyenforcement via the created policy enforcement rules in association witheach implementation. As such, for any of the examples below, it isunderstood that any aspect of functionality described with respect toany one device that is described in conjunction with another device(e.g., sends/sending, etc.) is to be understood to concurrently describethe functionality of the other respective device (e.g.,receives/receiving, etc.).

A central processing unit (CPU) 202 provides computer instructionexecution, computation, and other capabilities within the coreprocessing module 200. A display 204 provides visual information to auser of the core processing module 200 and an input device 206 providesinput capabilities for the user.

The display 204 may include any display device, such as a cathode raytube (CRT), liquid crystal display (LCD), light emitting diode (LED),electronic ink displays, projection, touchscreen, or other displayelement or panel. The input device 206 may include a computer keyboard,a keypad, a mouse, a pen, a joystick, touchscreen, or any other type ofinput device by which the user may interact with and respond toinformation on the display 204.

It should be noted that the display 204 and the input device 206 may beoptional components for the core processing module 200 for certainimplementations/devices. Accordingly, the core processing module 200 mayoperate as a completely automated embedded device without direct userconfigurability or feedback. However, the core processing module 200 mayalso provide user feedback and configurability via the display 204 andthe input device 206, respectively, as appropriate for a givenimplementation.

A communication module 208 provides interconnection capabilities thatallow the core processing module 200 to communicate with other moduleswithin the system 100. The communication module 208 may include anyelectrical, protocol, and protocol conversion capabilities useable toprovide interconnection capabilities, appropriate for a givenimplementation.

A memory 210 includes a policy processing storage area 212 that providesmemory space for the creation of policies (e.g., SLAs and SLDs) inassociation with the core processing module 200 when implemented, forexample, in association with one or more of the service providerserver_(—)1 116 through the service provider server_M 118. Additionally,the policy processing storage area 212 provides memory space for thecreation of policy enforcement rules and associated runtime processingactions to support the runtime enforcement of defined policies (e.g.,SLAs and SLDs) in association with the core processing module 200 whenimplemented, for example, in association with one or more of the policyenforcement server_(—)1 108 through the policy enforcement server_T 110.

The policy processing storage area 212 also provides storage for policyproxy objects that operate as intermediate effective policies thatencapsulate policy information from repository service policies that isusable for runtime policy enforcement. As described above, creation ofpolicy enforcement rules that include runtime processing rules andprocessing actions to support the runtime enforcement of definedpolicies involves the creation of intermediate policy proxy objects thatinclude information from the original policy that is undertransformation. These intermediate policy proxy objects provide aframework and foundation for creation of the actual runtime policyenforcement rules including the processing rules and processing actions.

The memory 210 also includes a policy enforcement processing rule andaction storage area 214 that provides storage space for created policyenforcement rules and associated runtime processing actions. Asdescribed above, the created policy enforcement rules and associatedruntime processing actions may be utilized for runtime enforcement ofdefined policies (e.g., SLAs and SLDs) in association with the coreprocessing module 200 when implemented, for example, in association withone or more of the policy enforcement server_(—)1 108 through the policyenforcement server_T 110.

It is understood that the memory 210 may include any combination ofvolatile and non-volatile memory suitable for the intended purpose,distributed or localized as appropriate, and may include other memorysegments not illustrated within the present example for ease ofillustration purposes. For example, the memory 210 may include a codestorage area, an operating system storage area, a code execution area,and a data area without departure from the scope of the present subjectmatter.

A policy framework module 216 is also illustrated. The policy frameworkmodule 216 provides policy enforcement rule creation and runtimeenforcement of processing actions for the core processing module 200, asdescribed above and in more detail below. The policy framework module216 implements the dynamic generation of policy enforcement rules andactions from policy attachment semantics of the core processing module200.

The policy framework module 216 includes several sub-components orsub-modules. A policy parser 218 parses policy definitions for SLDs andSLAs to identify policy constraints to be implemented during runtimeprocessing of messages. A processing rule generator (PRG) 220 generatespolicy enforcement rules from the runtime constraints associated withpolicies parsed by the policy parser 218. A policy domain assertion topolicy action mapper 222 provides policy mapping to policy enforcementrules within the policy framework module 216. Given a policy domain anda list of assertions, the policy domain assertion to policy actionmapper 222 maps or converts each policy domain assertion identifiedwithin the runtime constraints parsed by the policy parser 218 tocorresponding runtime processing actions to be enforced for messagesprocessed by the policy framework module 216. The processing rulegenerator (PRG) 220 then populates the respective created policyenforcement rule with the created runtime processing actions. Thecreated policy enforcement rules and processing actions may be storedwithin the policy enforcement processing rule and action storage area214 of the memory 210. A policy enforcement module 224 implements thecreated policy enforcement rules and runtime processing actions createdfrom the original policy definitions.

It should also be noted that the policy framework module 216 may form aportion of other circuitry described without departure from the scope ofthe present subject matter. Further, the policy framework module 216 mayalternatively be implemented as an application stored within the memory210. In such an implementation, the policy framework module 216 mayinclude instructions executed by the CPU 202 for performing thefunctionality described herein. The CPU 202 may execute theseinstructions to provide the processing capabilities described above andin more detail below for the core processing module 200. The policyframework module 216 may form a portion of an interrupt service routine(ISR), a portion of an operating system, a portion of a browserapplication, or a portion of a separate application without departurefrom the scope of the present subject matter.

The policy registry 114 is also shown associated with the coreprocessing module 200 within FIG. 2 to show that the policy registry 114may be coupled to the core processing module 200 without requiringexternal connectivity, such as via the network 106 or the network 112.

The CPU 202, the display 204, the input device 206, the communicationmodule 208, the memory 210, the policy framework module 216, and thepolicy registry 114 are interconnected via an interconnection 226. Theinterconnection 226 may include a system bus, a network, or any otherinterconnection capable of providing the respective components withsuitable interconnection for the respective purpose.

Though the different modules illustrated within FIG. 2 are illustratedas component-level modules for ease of illustration and descriptionpurposes, it should be noted that these modules may include anyhardware, programmed processor(s), and memory used to carry out thefunctions of the respective modules as described above and in moredetail below. For example, the modules may include additional controllercircuitry in the form of application specific integrated circuits(ASICs), processors, antennas, and/or discrete integrated circuits andcomponents for performing communication and electrical controlactivities associated with the respective modules. Additionally, themodules may include interrupt-level, stack-level, and application-levelmodules as appropriate. Furthermore, the modules may include any memorycomponents used for storage, execution, and data processing forperforming processing activities associated with the respective modules.The modules may also form a portion of other circuitry described or maybe combined without departure from the scope of the present subjectmatter.

Additionally, while the core processing module 200 is illustrated withand has certain components described, other modules and components maybe associated with the core processing module 200 without departure fromthe scope of the present subject matter. Additionally, it should benoted that, while the core processing module 200 is described as asingle device for ease of illustration purposes, the components withinthe core processing module 200 may be co-located or distributed andinterconnected via a network without departure from the scope of thepresent subject matter. For a distributed arrangement, the display 204and the input device 206 may be located at a point of sale device,kiosk, or other location, while the CPU 202 and memory 210 may belocated at a local or remote server. Many other possible arrangementsfor components of the core processing module 200 are possible and allare considered within the scope of the present subject matter. It shouldalso be understood that, though the policy registry 114 is illustratedas a separate component for purposes of example, the information storedwithin the policy registry 114 may also/alternatively be stored withinthe memory 210 without departure from the scope of the present subjectmatter. Accordingly, the core processing module 200 may take many formsand may be associated with many platforms.

FIG. 3 through FIG. 5 described below represent example processing flowsfor transformation of different policy types to policy enforcementrules. The example processing flows for transformation of differentpolicy types to policy enforcement rules represented within FIG. 3through FIG. 5 are described for purposes of example. However, it shouldbe noted that many possibilities exist for policy transformation forenforcement in association with one or more PEPs, and all suchpossibilities are considered within the scope of the present technology.

FIG. 3 is a diagram of an example of an implementation of a policytransformation flow 300 for dynamic generation of policy enforcementrules and actions from policy attachment semantics for a service leveldefinition (SLD). As can be seen from FIG. 3, certain sub-components ofthe policy framework module 216 are represented, specifically the policyparser 218, the processing rule generator (PRG) 220, and the policydomain assertion to policy action mapper 222. To avoid congestion withinthe drawing, the reference numerals of the respective components aredepicted rather than associated text names.

A policy_B1 302 represents an SLD of a service provider that is to beenforced by a PEP. The policy parser 218 consumes the originalrepresentation of the policy_B1 302 and generates/creates a number ofpolicy proxy objects from the original policy_B1 302. The generatedpolicy proxy objects within the present example include proxypolicy_(—)1 304 through policy proxy_N 306. Each of the proxypolicy_(—)1 304 through the proxy policy_N 306 contains similarinformation, based upon information within the original policy_B1 302.The effective policies represent locally-created processing entitiesthat specify policy enforcement constraints (e.g., such as policysubjects, credentials, assertions, etc.) to be enforced by a PEP basedupon policy information and enforceable policy provisions within thepolicy_B1 302. As such, the effective policies map the policyinformation and enforceable policy provisions within the policy_B1 302to policy enforcement constraints from which processing rules andprocessing actions may be created.

A policy subject 308 is shown within the proxy policy_(—)1 304 to beattached to a “service” policy subject. In the proxy policy_N 306, thepolicy subject 308 is shown to be attached to an “operation” policysubject. As such, the respective effective policies have been createdfrom information within the policy_B1 302 and have been attached todifferent policy subjects for eventual enforcement.

A policy domain 310 within the proxy policy_(—)1 304 identifies auniform resource locator (URL) that represents, for purposes of example,a location of a policy domain to be enforced. It should be noted thatother forms of identification of policy domains are possible and allsuch possibilities are considered to be within the scope of the presentsubject matter. Within the present example, the URL is illustrated withellipsis dots for convenience to represent an accessible storagelocation that references a security policy domain of “2432039.” A policydomain 310 within the proxy policy_N 306 references the same policydomain as the policy domain 310 within the proxy policy_(—)1 304.

The proxy policy_(—)1 304 also includes an SLD assertions identifier 312with a value of “USERNAME TOKEN 1.0” that maps, for example, to a“sp:WssUsernameToken10” policy constraint associated within thepolicy_B1 302. An example of such a policy was described in associationwith the pseudo-syntax policy example above. An SLD assertionsidentifier 312 within the proxy policy_N 306 includes a value of“USERNAME TOKEN 2.0.” As such, each of the respective SLD assertionidentifiers 312 may include different assertions, as specified by theSLD policy_B1 302.

Each of the effective policies parsed and generated from the policy_B1302 may then be processed one by one by the processing rule generator(PRG) 220 to create a processing rule for each proxy policy object. Thecollection/set of processing rules that result are represented as apolicy enforcement rule 314. To generate the policy enforcement rule 314with its set of processing rules that include the respective processingactions, the PRG 220 calls/invokes the policy domain assertion to policyaction mapper 222 sub-component to process each proxy policy 304 through306, as represented for each of the proxy policy 304 through 306 by thesingle arrow 316. The PRG 220 passes the policy domain and list ofassertions for that particular domain to the policy domain assertion topolicy action mapper 222.

In response to being invoked with the policy domain and list ofassertions for that particular domain, the policy domain assertion topolicy action mapper 222 maps or converts (e.g., transforms) each ofthose assertions to create corresponding processing actions 318. Thepolicy domain assertion to policy action mapper 222 returns the createdprocessing actions 318 to the PRG 220, as represented by the arrow 320.The PRG 220 then populates the processing rule 314 with the createdprocessing actions 318. The PRG 220 iteratively processes each proxypolicy 304 through 306 and creates a corresponding processing rulewithin the policy enforcement rule 314. The PRG 220 outputs the createdpolicy enforcement rule 314 to each PEP that is tasked with policyenforcement for the particular SLD(s) associated with the policy_B1 302.As such, the policy framework module 216 generates policy enforcementrules (processing rules for each proxy policy object that includeprocessing actions to be performed) from the runtime constraintsassociated with policies and distributes the created policy enforcementrules to the respective PEPs to enforce. This processing may beperformed for each policy and for each SLD.

Additional complexities exist with respect to enforcement of SLAs. Forexample, with SLAs, the task of the policy framework module 216described above is more complicated. A policy subject may contain anumber of SLAs. These SLAs are determined at runtime based upon thecontents (e.g., user credentials, etc.) of the respective objects beingprocessed to determine which, if any, policy enforcement rules are to beenforced.

FIG. 4 is diagram of an example of an implementation of a policytransformation flow 400 for dynamic generation of policy enforcementrules and actions from policy attachment semantics for a service leveldefinition (SLD) and service level agreements (SLAs), and runtimeenforcement. The policy framework module 216 is again illustrated alongwith the policy_B1 302 as described above. The policy enforcement rule314 that defines processing rules (and processing actions) forenforcement of the policy_B1 302 is again illustrated.

Additionally, an SLA policy_S1 402, an SLA policy_S2 404, and an SLApolicy_S3 406 are illustrated. The policy framework 216 consumes the SLApolicies 402 through 406. Within this example, the SLAs would beattached at a “service” policy-subject. The policy framework module 216creates a parent processing rule for the “service” policy subject. Theparent processing rule includes an SLA check action 408, and for-eachmatch and enforce operation (loop) logic 410 used to select processingrules to be applied during runtime to enforce the respective SLApolicies 402 through 406.

The SLA check action 408 includes requirements specified in the SLApolicies 402 through 406 to match against during runtime, along with thecorresponding processing rule that contains the respective policyimplementation. During runtime, the SLA check action 408 outputs a listof zero (0) or more processing rules 412 that match content (e.g., usercredentials, etc.) within the particular message being processed. Thefor-each match and enforce operation (loop) logic 410 may then take thelist of matching processing rules 412 and make a call to apply each ofthe matching processing rules 412, one by one. The processing actionsfrom the SLD policy_B1 302, if any, may then be enforced after thematching SLA processing rules 412.

FIG. 5 is diagram of an example of an implementation of a policytransformation flow 500 for dynamic generation of policy enforcementrules and actions from policy attachment semantics for a service leveldefinition (SLD) and service level agreements (SLAs) based upon theexample SLD and SLAs described in FIG. 4. As can be seen from FIG. 5,again certain sub-components of the policy framework module 216 arerepresented, specifically the policy parser 218, the processing rulegenerator (PRG) 220, and the policy domain assertion to policy actionmapper 222 depicted. To avoid congestion within the drawing, thereference numerals of the respective components are depicted rather thanassociated text names. As well, the policy_B1 302 that represents an SLDof a service provider, and the SLA policy_S1 402, SLA policy_S2 404, andSLA policy_S3 406 of FIG. 4 are again illustrated.

A proxy policy_(—)1 502 is illustrated. It is understood that manyeffective policies may be created based upon a set of policiesrepresented by the SLD policy_B1 302 and the SLA policies 402 through406. However, because of the detail illustrated within the proxypolicy_(—)1 502 in FIG. 5, only this one proxy policy object isillustrated. The ellipsis dots below the proxy policy_(—)1 502 representthe continuation of the created effective policies to include theadditional effective policies that may be created.

Within this example, the policy parser 218 annotates each proxy policyobject with additional information, along with the associated SLD policyassertion(s) from the Policy_B1 302, the credentials that are to bematched for each SLA, and the corresponding assertions that are to beused to enforce the respective policies. As can be seen from FIG. 6, anSLD proxy policy portion 504 represents a similar effective policy asthe proxy policy_(—)1 304 of FIG. 3. As such, additional description ofthis portion of the proxy policy_(—)1 502 may be obtained with referenceto FIG. 3 as described above.

Additionally, an effective proxy policy object for each of the SLApolicy_S1 402, SLA policy_S2 404, and SLA policy_S3 406 is representedin association with the proxy policy_(—)1 502. The policy parser 218creates an effective SLA proxy policy_(—)1 506 from the SLA policy_S1402, creates an effective SLA proxy policy_(—)2 508 from the SLApolicy_S2 404, and creates an effective SLA proxy policy_(—)3 510 fromthe SLA policy_S3 406. As can be seen within the effective SLA proxypolicy_(—)1 506, each of the effective SLA proxy policy_(—)1 506, theeffective SLA proxy policy_(—)2 508, and the effective SLA proxypolicy_(—)3 510 form a portion of the proxy policy_(—)1 502.

Each of the effective SLA proxy policy_(—)1 506, the effective SLA proxypolicy_(—)2 508, and the effective SLA proxy policy_(—)3 510 includes acredentials field 512 and an assertions field 514. Within the effectiveSLA proxy policy_(—)1 506, the value of the credentials field 512 is“USERID=JOHN DOE.” As such, messages that are processed during runtimewith a user identifier of “JOHN DOE” will be identified, and theeffective SLA proxy policy_(—)1 506 selected for processing thosemessages. The value of the assertions field 514 within the effective SLAproxy policy_(—)1 506 is set to “ROUTE MESSAGE,” which indicates thatmessages associated with this user identifier are to be routed withoutany additional transformation or encoding. Additionally, it should benoted that the inclusion of the user identifier for “JOHN DOE,” and onlythat user identifier, also satisfies the “ExactlyOne” policy provisionto be enforced for the SLD policy_B1 302.

Within the effective SLA proxy policy_(—)2 508, the value of thecredentials field 512 is “USERID=JANE DOE.” As such, messages that areprocessed during runtime with a user identifier of “JANE DOE” will beidentified, and the effective SLA proxy policy_(—)2 508 selected forprocessing those messages. The value of the assertions field 514 withinthe effective SLA proxy policy_(—)2 508 is set to “TRANSFORM MESSAGE,”which indicates that messages associated with this user identifier areto be transformed. Any transformation appropriate for a given SLA andimplementation may be utilized. Additionally, it should be noted thatthe inclusion of the user identifier for “JANE DOE,” and only that useridentifier, also satisfies the “ExactlyOne” policy provision to beenforced for the SLD policy_B1 302.

Within the effective SLA proxy policy_(—)3 510, the value of thecredentials field 512 is “USERID=JOHN SMITH.” As such, messages that areprocessed during runtime with a user identifier of “JOHN SMITH” will beidentified, and the effective SLA proxy policy_(—)3 510 selected forprocessing those messages. The value of the assertions field 514 withinthe effective SLA proxy policy_(—)3 510 is set to “ENCRYPT MESSAGE,”which indicates that messages associated with this user identifier areto be encrypted. Any encryption protocol/technique appropriate for agiven SLA and implementation may be utilized. For example, a message maybe encrypted using RSA, AES, or 3DES, or other encryption protocols asappropriate for a given implementation. Additionally, it should be notedthat the inclusion of the user identifier for “JOHN SMITH,” and onlythat user identifier, also satisfies the “ExactlyOne” policy provisionto be enforced for the SLD proxy policy_B1 302.

As described above in association with FIG. 3, the processing rulegenerator (PRG) 220 again interacts with the policy domain assertion topolicy action mapper 222. Each of the effective proxy policies generatedfrom the policy_B1 302 and the SLA policies 402 through 406 (e.g., theSLA proxy policy_(—)1 502 and others) may then be processed one by oneby the processing rule generator (PRG) 220 to create a processing rulefor each proxy policy object (e.g., effective policy). Thecollection/set of processing rules that result are represented as apolicy enforcement rule 516. To generate the policy enforcement rule 516with its set of processing rules that include the respective processingactions, the PRG 220 calls/invokes the policy domain assertion to policyaction mapper 222 sub-component to process each proxy policy object, asrepresented for each proxy policy object by the single arrow 518. ThePRG 220 passes the policy domain and list of assertions for thatparticular domain to the policy domain assertion to policy action mapper222.

In response to being invoked with the policy domain and list ofassertions for that particular domain, the policy domain assertion topolicy action mapper 222 maps or converts (e.g., transforms) each ofthose assertions to create corresponding processing actions 520. Thepolicy domain assertion to policy action mapper 222 returns the createdprocessing actions 520 to the PRG 220, as represented by the arrow 522.The PRG 220 then populates the processing rule 516 with the createdprocessing actions 520. The PRG 220 iteratively processes each proxypolicy object (e.g., the SLA proxy policy_(—)1 502 and others) andcreates a corresponding processing rule within the policy enforcementrule 516. The PRG 220 outputs the created policy enforcement rule 516 toeach PEP that is tasked with policy enforcement for the particularSLD(s) associated with the policy_B1 302 and the SLA policies 402through 406. As such, the policy framework module 216 generates policyenforcement rules (processing rules for each proxy policy object thatinclude processing actions to be performed) from the runtime constraintsassociated with policies, and distributes the created policy enforcementrules to the respective PEPs to enforce. This processing may beperformed for each policy, for each SLD, and for each SLA.

Regarding additional details of the created policy enforcement rule 516,the PRG 220 may again create the parent rule (represented within thefirst row of the policy enforcement rule 516). The PRG 220 may populatethe parent rule with an SLA Check action (represented by the “S” withinthe first row, first element of the policy enforcement rule 516). Then,for each SLA policy, the PRG 220 may append the credentials match to theSLA check action, create another empty rule, and append the rule name tothe SLA check action. This new processing rule may then be populatedwith the processing actions that result from the assertions of therespective SLA policy 402 through 406 (represented by the additionalrows of the policy enforcement rule 516).

Once processing to transform all the SLA policies to SLA processingrules and processing actions has been completed, the for-each andenforce operation (represented by the “F” within the first row, secondelement, of the policy enforcement rule 516) may be added to the parentprocessing rule. The SLA processing rules may be added/appended to theparent processing rule as child processing rules to form a completedpolicy enforcement rule usable to enforce the provision of the originalpolicy.

During runtime enforcement, the loop construct associated with thefor-each and enforce operation takes in as input the list of processingrule names for SLA processing rules generated by the SLA check action.For each rule name, the process iteratively calls or enforces therespective processing rules, and thereby enforces the processing actionscontained within the respective processing rules. The SLD processingrule(s) generated from the SLD assertions may also be appended to theparent processing rule (represented by the remainder of the first row ofthe policy enforcement rule 516). The SLD processing rule(s) may beapplied after the SLA processing rules have been applied.

As such, the policy framework 216 provides dynamic rule creation andprocessing. As any change to a policy is made, the processing rules andactions associated with the respective policy may be recreated by thepolicy framework 216, the previous processing rules and processingactions may be removed and replaced by the newly-created processingrules and processing actions. Accordingly, policy implementation andenforcement, policy maintenance, and policy adaptation to changes may beimproved by use of the present technology.

FIG. 6 through FIG. 8 described below represent example processes thatmay be executed by devices, such as the core processing module 200, toperform the dynamic generation of policy enforcement rules and actionsfrom policy attachment semantics associated with the present subjectmatter. Many other variations on the example processes are possible andall are considered within the scope of the present subject matter. Theexample processes may be performed by modules, such as the policyframework module 216 and/or executed by the CPU 202, associated withsuch devices. It should be noted that time out procedures and othererror control procedures are not illustrated within the exampleprocesses described below for ease of illustration purposes. However, itis understood that all such procedures are considered to be within thescope of the present subject matter. Further, the described processesmay be combined, sequences of the processing described may be changed,and additional processing may be added or removed without departure fromthe scope of the present subject matter.

FIG. 6 is a flow chart of an example of an implementation of a process600 for dynamic generation of policy enforcement rules and actions frompolicy attachment semantics. At block 602, the process 600 obtains, by aprocessor, at least one defined service policy to be enforced by apolicy enforcement point (PEP). At block 604, the process 600 parses theobtained at least one defined service policy to identify at least oneset of enforceable policy provisions. At block 606, the process 600identifies the at least one set of enforceable policy provisions, whereeach set of enforceable policy provisions comprises a policy subject, apolicy domain, and at least one assertion as the enforceable policyprovisions within the at least one defined service policy. At block 608,the process 600 creates at least one runtime processing rule comprisingat least one processing action usable by the PEP to enforce the policysubject, the policy domain, and the at least one assertion of eachidentified at least one set of enforceable policy provisions.

FIG. 7 is a flow chart of an example of an implementation of a process700 for dynamic generation of policy enforcement rules and actions frompolicy attachment semantics for both service level definitions (SLDs)and service level agreements (SLAs). At decision point 702, the process700 makes a determination as to whether a request to define processingrules and processing actions (collectively policy enforcement rules) forone or more defined service policies has been detected. A request todefine policy enforcement rules may be detected, for example, inresponse to an addition of a new service policy definition or a changeto an existing service policy definition within a policy repository,such as the policy registry 114, or may be detected otherwise asappropriate for a given implementation.

In response to determining at decision point 702 that a request todefine processing rules and processing actions (collectively policyenforcement rules) for one or more defined service policies has beendetected, the process 700 selects/obtains a defined service policy toprocess at block 704. The selected service policy may be, for example, aservice level definition (SLD) that protects service providerinfrastructure access and utilization constraints, or may be a servicelevel agreement (SLA) that represents an agreement for services and alevel of service between a service provider and a consumer.

At block 706, the process 700 parses the selected service policy toidentify enforceable policy provisions. At block 708, the process 700identifies enforceable policy provisions within the parsed servicepolicy. It should be noted, that the identified enforceable policyprovisions may include a policy subject, a policy domain, and at leastone assertion. It should further be noted, that there may be one or moresets of enforceable policy provisions within the parsed service policy,as described above. At block 710, the process 700 generates at least onelocal proxy policy object that includes policy enforcement constraintsbased upon the identified policy subject, policy domain, and at leastone assertion of the at least one defined service policy that representthe enforceable policy provisions. At block 712, the process 700populates each proxy policy object with the identified enforceablepolicy provisions.

At block 714, the process 700 begins iterative processing of thegenerated proxy policy objects to map the generated proxy policy objectsto runtime-executable processing rules and processing actions, andselects a proxy policy object to map. At block 716, the process 700defines/creates at least one runtime processing rule that includes atleast one processing action usable by the PEP to enforce the identifiedpolicy subject, policy domain, and at least one assertion of the definedservice policy represented by the selected policy proxy object.

At decision point 718, the process 700 makes a determination as towhether mapping of the generated proxy policy objects to processingrules and processing actions is completed. In response to determiningthat at least one additional proxy policy object is available to map toruntime-executable processing rules and processing actions (i.e., themapping is not completed), the process 700 returns to block 714 anditerates as described above.

In response to determining at decision point 718 that all generatedproxy policy objects have been mapped to runtime-executable processingrules and processing actions, the process 700 makes a determination atdecision point 720 as to whether the mapped proxy policy objectsrepresent one or more SLD policies only, or whether the mapped proxypolicy objects additionally represent one or more SLAs. In response todetermining that the mapped proxy policy objects represent one or moreSLD policies only, the process 700 forms an SLD policy enforcement rulefrom the mapped processing rules and processing actions at block 722.

Returning to the description of decision point 720, in response todetermining that the mapped proxy policy objects additionally representone or more SLAs, at block 724 the process 700 creates one or moreservice level agreement (SLA) check actions usable to select SLAprocessing rules during runtime based upon the contents of the objectsunder processing during runtime. At block 726, the process 700 generatesruntime SLA processing logic to identify matching SLA processing rulesto be applied to objects during runtime for SLA policy enforcement. Asdescribed above, the generated runtime SLA processing logic may includea for-each match loop that processes and enforces each appropriate SLAprocessing rule based upon the contents of the object under processingduring runtime. At block 728, the process 700 forms a policy enforcementrule populated with the SLA check action and the runtime SLA processinglogic, and designates the SLA processing rule as a parent processingrule within the policy enforcement rule. At block 730, the process 700appends one or more processing rules that include one or more processingactions mapped from the respective SLA policy proxy objects. Asdescribed above, the processing rules and processing actions mapped fromthe SLA policy proxy objects are useable during runtime to enforce thedefined SLA policies.

In response to appending the SLA processing rules to the policyenforcement rule at block 730, or in response to forming the SLD policyenforcement rule at block 722, the process 700 distributes the generatedpolicy enforcement rule to one or more policy enforcement points (PEPs)at block 732. Where the process 700 is executed by a policy enforcementpoint, distribution of the generated policy enforcement rule may includelocally implementing the generated policy enforcement rule, and may alsoinclude distribution of the generated policy enforcement rule to one ormore other PEPs. The process 700 returns to decision point 702 anditerates as described above.

As such, the process 700 obtains defined service policies reinforced byone or more PEPs, generates proxy policy objects based upon the contentsof the defined service policies, maps generated proxy policy objects toprocessing rules and processing actions, and generates policyenforcement rules. The generated policy enforcement rules are usableduring runtime to enforce the original defined service policies at oneor more PEPs. The process 700 distributes the generated policyenforcement rules for enforcement to one or more PEPs to deploy thegenerated policy enforcement rules. It should be noted that the process700 is dynamic and may be triggered at any time to update deployedpolicy enforcement rules based upon changes to service policydefinitions and/or the addition or deletion of defined service policies.Accordingly, the process 700 provides a flexible and manageable platformby which to deploy and maintain enforcement logic for defined servicepolicies.

FIG. 8 is a flow chart of an example of an implementation of a process800 for dynamic deployment and enforcement of policy enforcement rulesand actions at policy enforcement points (PEPs). The process 800 may beimplemented, for example, at a PEP. At decision point 802, the process800 makes a determination as to whether one or more policy enforcementrules have been received or created locally based upon defined servicepolicies. It should be noted, as described above, that the policyenforcement rules may be created dynamically in response to changes todefined service policies or additions and deletions of defined servicepolicies. A process such as the process 700 described above inassociation with FIG. 7 may be used to dynamically create policyenforcement rules and the output of such a process may be provided tothe process 800 for enforcement of the dynamically created policyenforcement rules.

In response to determining that one or more policy enforcement ruleshave not been received, the process 800 makes a determination atdecision point 804 as to whether an object for which runtime enforcementof policy enforcement rules has been received. The respective object maybe received from a service provider or from a customer. As describedabove, the object may include a service request selected such as atransaction, a web request, a database request, a representational statetransfer (REST) service, and a web application, a message, or any otherobject for which policy enforcement may be enforced. As also describedabove, a PEP that executes a process such as the process 800 acts as aproxy for both a service provider and a customer between which theobject is communicated. In response to determining at decision point 804that an object for which runtime enforcement of policy enforcement ruleshas not been received, the process 800 returns to decision point 802 anditerates as described above.

In response to determining at decision point 802 that one or more policyenforcement rules has been received or created locally based upondefined service policies, the process 800 stores the respective policyenforcement rule(s) at block 806. At block 808, the process 800configures enforcement of the respective policy enforcement rule(s). Assuch, the respective policy enforcement rules may be enforced by thePEP. Returning to the description of decision point 804, in response todetermining that an object for which runtime enforcement of policyenforcement rules has been received, the process 800 identifies adefined policy enforcement rule that includes the defined runtimeprocessing rule(s) applicable to enforce the defined service policy forwhich the policy enforcement rule was created against the object duringruntime at block 810.

As described above, processing rules may include SLD processing rulesand may also include SLA processing rules. Where both an SLD processingrule and one or more SLA processing rules are included in the samepolicy enforcement rule, the SLD processing rule is considered a parentprocessing rule and is configured to be executed after any child SLAprocessing rules. As such, at decision point 812, the process 800 makesa determination as to whether the defined policy enforcement ruleincludes one or more SLD processing rules for enforcement of a definedSLD policy only, or whether the defined policy enforcement rule includesprocessing rules for enforcement of one or more SLAs in addition to anSLD.

In response to determining at decision point 812 that the defined policyenforcement rule additionally includes at least one processing rule forenforcement of one or more SLAs, the process 800 performs an SLA checkaction on the object to identify the appropriate SLA processing rule(s)at block 814. As also described above, the processing for SLAenforcement is dynamic and is based upon the contents of the object atruntime. As such, the process 800 may, for example, determine a firstSLA processing rule associated with a first user credential for oneobject and may determine a second/different SLA processing ruleassociated with a second user credential for another object.Accordingly, the process 800 may dynamically adjust the processingactions of the defined processing rules according to the first SLAprocessing rule of the first user credential and according to the secondSLA processing rule for the second user credential. Many othervariations on dynamic SLA processing rule selection and enforcement arepossible and all are considered to be within the scope of the presentsubject matter.

At decision point 816, the process 800 makes a determination as towhether the SLA check action identified any matching SLA processingrules to be enforced against the object. In response to determining thatat least one matching SLA processing rule has been identified to beenforced against the object, the process 800 performs iterativeprocessing for each matching SLA processing rule to process the objectusing the respective matching SLA processing rule(s) at block 818.

In response to determining at decision point 816 that no matching SLAprocessing rules have been identified to be enforced against the object,or in response to processing the object using each matching SLAprocessing rule at block 818, or in response to determining at decisionpoint 812 that the defined policy enforcement rule only includes one ormore SLD processing rules for enforcement of a defined SLD policy, theprocess 800 proceeds to process the object using the SLD policyenforcement rule at block 820. As described above, in the case of apolicy enforcement rule that includes both SLD and SLA processing rules,the SLD policy enforcement rule is considered the parent processing ruleand is configured to be executed after any child SLA processing rules.As such, the process 800 enforces the respective SLD processing rule(s)last after processing each matching SLA processing rule on the object,where appropriate.

At decision point 822, the process 800 makes a determination as towhether the object is authorized to be forwarded to the destinationbased upon the applied policy enforcement rule. In response todetermining that the object is authorized to be forwarded to thedestination based upon the applied policy enforcement rule, the process800 forwards the object to the destination at block 824. In response todetermining that the object is not authorized to be forwarded to thedestination based upon the applied policy enforcement rule, the process800 generates a notification (e.g., error notification, log entry, etc.)at block 826, and does not forward the object to the destination. Inresponse to either forwarding the object to the destination at block 824or in response to generating the notification at block 826, the process800 returns to decision point 802 and iterates as described above.

As such, policy enforcement within a policy enforcement point (PEP) maybe implemented using a process such as the process 800 to dynamicallyprocess objects based upon content of the objects during runtime. Thisprocessing may be based upon defined runtime processing rules thatinclude runtime processing actions that enforce defined service policiesfor service providers and contractual agreements between serviceproviders and customers.

As described above in association with FIG. 1 through FIG. 8, theexample systems and processes provide dynamic generation of policyenforcement rules and actions from policy attachment semantics. Manyother variations and additional activities associated with dynamicgeneration of policy enforcement rules and actions from policyattachment semantics are possible and all are considered within thescope of the present subject matter.

Those skilled in the art will recognize, upon consideration of the aboveteachings, that certain of the above examples are based upon use of aprogrammed processor, such as the CPU 202. However, the invention is notlimited to such example embodiments, since other embodiments could beimplemented using hardware component equivalents such as special purposehardware and/or dedicated processors. Similarly, general purposecomputers, microprocessor based computers, micro-controllers, opticalcomputers, analog computers, dedicated processors, application specificcircuits and/or dedicated hard wired logic may be used to constructalternative equivalent embodiments.

As will be appreciated by one skilled in the art, aspects of the presentinvention may be embodied as a system, method or computer programproduct. Accordingly, aspects of the present invention may take the formof an entirely hardware embodiment, an entirely software embodiment(including firmware, resident software, micro-code, etc.) or anembodiment combining software and hardware aspects that may allgenerally be referred to herein as a “circuit,” “module” or “system.”Furthermore, aspects of the present invention may take the form of acomputer program product embodied in one or more computer readablemedium(s) having computer readable program code embodied thereon.

Any combination of one or more computer readable medium(s) may beutilized. The computer readable medium may be a computer readable signalmedium or a computer readable storage medium. A computer readablestorage medium may be, for example, but not limited to, an electronic,magnetic, optical, electromagnetic, infrared, or semiconductor system,apparatus, or device, or any suitable combination of the foregoing. Morespecific examples (a non-exhaustive list) of the computer readablestorage medium would include the following: an electrical connectionhaving one or more wires, a portable computer diskette, a hard disk, arandom access memory (RAM), a read-only memory (ROM), an erasableprogrammable read-only memory (EPROM or Flash memory), a portablecompact disc read-only memory (CD-ROM), an optical storage device, amagnetic storage device, or any suitable combination of the foregoing.In the context of this document, a computer readable storage medium maybe any tangible medium that can contain, or store a program for use byor in connection with an instruction execution system, apparatus, ordevice.

A computer readable signal medium may include a propagated data signalwith computer readable program code embodied therein, for example, inbaseband or as part of a carrier wave. Such a propagated signal may takeany of a variety of forms, including, but not limited to,electro-magnetic, optical, or any suitable combination thereof. Acomputer readable signal medium may be any computer readable medium thatis not a computer readable storage medium and that can communicate,propagate, or transport a program for use by or in connection with aninstruction execution system, apparatus, or device.

Program code embodied on a computer readable medium may be transmittedusing any appropriate medium, including but not limited to wireless,wireline, optical fiber cable, RF, etc., or any suitable combination ofthe foregoing.

Computer program code for carrying out operations for aspects of thepresent invention may be written in any combination of one or moreprogramming languages, including an object oriented programming languagesuch as JAVA™, Smalltalk, C++ or the like and conventional proceduralprogramming languages, such as the “C” programming language or similarprogramming languages. The program code may execute entirely on theuser's computer, partly on the user's computer, as a stand-alonesoftware package, partly on the user's computer and partly on a remotecomputer or entirely on the remote computer or server. In the latterscenario, the remote computer may be connected to the user's computerthrough any type of network, including a local area network (LAN) or awide area network (WAN), or the connection may be made to an externalcomputer (for example, through the Internet using an Internet ServiceProvider).

Aspects of the present invention have been described with reference toflowchart illustrations and/or block diagrams of methods, apparatus(systems) and computer program products according to embodiments of theinvention. It will be understood that each block of the flowchartillustrations and/or block diagrams, and combinations of blocks in theflowchart illustrations and/or block diagrams, can be implemented bycomputer program instructions. These computer program instructions maybe provided to a processor of a general purpose computer, specialpurpose computer, or other programmable data processing apparatus toproduce a machine, such that the instructions, which execute via theprocessor of the computer or other programmable data processingapparatus, create means for implementing the functions/acts specified inthe flowchart and/or block diagram block or blocks.

These computer program instructions may also be stored in acomputer-readable storage medium that can direct a computer or otherprogrammable data processing apparatus to function in a particularmanner, such that the instructions stored in the computer-readablestorage medium produce an article of manufacture including instructionswhich implement the function/act specified in the flowchart and/or blockdiagram block or blocks.

The computer program instructions may also be loaded onto a computer,other programmable data processing apparatus, or other devices to causea series of operational steps to be performed on the computer, otherprogrammable apparatus or other devices to produce a computerimplemented process such that the instructions which execute on thecomputer or other programmable apparatus provide processes forimplementing the functions/acts specified in the flowchart and/or blockdiagram block or blocks.

The flowchart and block diagrams in the Figures illustrate thearchitecture, functionality, and operation of possible implementationsof systems, methods and computer program products according to variousembodiments of the present invention. In this regard, each block in theflowchart or block diagrams may represent a module, segment, or portionof code, which comprises one or more executable instructions forimplementing the specified logical function(s). It should also be notedthat, in some alternative implementations, the functions noted in theblock may occur out of the order noted in the figures. For example, twoblocks shown in succession may, in fact, be executed substantiallyconcurrently, or the blocks may sometimes be executed in the reverseorder, depending upon the functionality involved. It will also be notedthat each block of the block diagrams and/or flowchart illustration, andcombinations of blocks in the block diagrams and/or flowchartillustration, can be implemented by special purpose hardware-basedsystems that perform the specified functions or acts, or combinations ofspecial purpose hardware and computer instructions.

A data processing system suitable for storing and/or executing programcode will include at least one processor coupled directly or indirectlyto memory elements through a system bus. The memory elements can includelocal memory employed during actual execution of the program code, bulkstorage, and cache memories which provide temporary storage of at leastsome program code in order to reduce the number of times code must beretrieved from bulk storage during execution.

Input/output or I/O devices (including but not limited to keyboards,displays, pointing devices, etc.) can be coupled to the system eitherdirectly or through intervening I/O controllers.

Network adapters may also be coupled to the system to enable the dataprocessing system to become coupled to other data processing systems orremote printers or storage devices through intervening private or publicnetworks. Modems, cable modems and Ethernet cards are just a few of thecurrently available types of network adapters.

The terminology used herein is for the purpose of describing particularembodiments only and is not intended to be limiting of the invention. Asused herein, the singular forms “a,” “an” and “the” are intended toinclude the plural forms as well, unless the context clearly indicatesotherwise. It will be further understood that the terms “comprises”and/or “comprising,” when used in this specification, specify thepresence of stated features, integers, steps, operations, elements,and/or components, but do not preclude the presence or addition of oneor more other features, integers, steps, operations, elements,components, and/or groups thereof.

The corresponding structures, materials, acts, and equivalents of allmeans or step plus function elements in the claims below are intended toinclude any structure, material, or act for performing the function incombination with other claimed elements as specifically claimed. Thedescription of the present invention has been presented for purposes ofillustration and description, but is not intended to be exhaustive orlimited to the invention in the form disclosed. Many modifications andvariations will be apparent to those of ordinary skill in the artwithout departing from the scope and spirit of the invention. Theembodiment was chosen and described in order to best explain theprinciples of the invention and the practical application, and to enableothers of ordinary skill in the art to understand the invention forvarious embodiments with various modifications as are suited to theparticular use contemplated.

What is claimed is:
 1. A method, comprising: obtaining, by a processor,at least one defined service policy to be enforced by a policyenforcement point (PEP); parsing the obtained at least one definedservice policy to identify at least one set of enforceable policyprovisions; identifying the at least one set of enforceable policyprovisions, where each set of enforceable policy provisions comprises apolicy subject, a policy domain, and at least one assertion as theenforceable policy provisions within the at least one defined servicepolicy; and creating at least one runtime processing rule comprising atleast one processing action usable by the PEP to enforce the policysubject, the policy domain, and the at least one assertion of eachidentified at least one set of enforceable policy provisions.
 2. Themethod of claim 1, further comprising: generating at least one localproxy policy object that encapsulates the at least one set of policyenforcement constraints of the at least one defined service policy; andwhere creating the at least one runtime processing rule comprising theat least one processing action usable by the PEP to enforce the policysubject, the policy domain, and the at least one assertion of eachidentified at least one set of enforceable policy provisions comprisescreating the at least one runtime processing rule from the generated atleast one local proxy policy object.
 3. The method of claim 1, wherecreating the at least one runtime processing rule comprising the atleast one processing action usable by the PEP to enforce the policysubject, the policy domain, and the at least one assertion of eachidentified at least one set of enforceable policy provisions comprisescreating, for each identified at least one set of enforceable policyprovisions, at least one processing action to be executed in response toa match of the policy subject, policy domain, and at least one assertionwithin a runtime object.
 4. The method of claim 1, further comprising:receiving an object in a policy framework; identifying a defined policyenforcement rule that comprises the created at least one runtimeprocessing rule applicable to enforce the at least one defined servicepolicy against the object during runtime; and enforcing the at least onedefined service policy on the object using the created at least oneruntime processing rule within the policy framework during the runtime.5. The method of claim 4, where enforcing the at least one definedservice policy on the object using the created at least one runtimeprocessing rule within the policy framework during runtime comprises:determining a first service level agreement (SLA) processing ruleassociated with a first user credential and a second SLA processing ruleassociated with a second user credential; and dynamically adjusting theat least one processing action of the created at least one runtimeprocessing rule according to the first SLA processing rule of the firstuser credential and according to the second SLA processing rule for thesecond user credential.
 6. The method of claim 4, where: the at leastone defined service policy comprises a service level agreement (SLA);the created at least one runtime processing rule comprises at least oneSLA processing rule; and enforcing the at least one defined servicepolicy on the object using the created at least one runtime processingrule within the policy framework during runtime comprises: performing anSLA check action on the object; determining whether the SLA check actionhas identified any matching SLA processing rules to be enforced againstthe object; and for each matching SLA processing rule, processing theobject using the matching SLA processing rule.
 7. The method of claim 6,where: the at least one defined service policy further comprises aservice level definition (SLD); the created at least one runtimeprocessing rule comprises at least one SLD processing rule; andenforcing the at least one defined service policy on the object usingthe created at least one runtime processing rule within the policyframework during runtime comprises: processing the at least one SLDprocessing rule last on the object after processing each matching SLAprocessing rule on the object.
 8. The method of claim 7, where theobject is selected from a service request selected from a groupconsisting of a transaction, a web request, a database request, arepresentational state transfer (REST) service, a web application, and amessage.